昨天在最後提出了所謂Release note的概念，其實就是要解決審核及查核人員的困境，那我們就應該要把相關的資訊，例如昨天列的那一系列證明我們是依照那些需求開發、進行了多少相關的測試、確認這次要上線的產物版本一致。
在進入到要提供上述的那些事務，第一個關卡就是AP Leader的關卡，他會需要審核程式碼修改的內容、相關的工作項目以及測試的結果。其實前兩項都可以在Pull request去完成，但測試結果會在Test Plan呈現，因此就會需要在PR的時候提供額外的資訊。
但在這之前我們先回到Pull Request 的Policy設定，在Day 8的時候有說到正式環境需要最少的reviewers 是2名，然後我們在最下面的Automatically included reviewers，指定了科長一定要做為reviewer。但是後來在內部討論後，我被問到萬一科長請假，代理人怎麼辦？因此討論不能寫死這件事情。
所以我們先跑去Project Settings -> Permissions，建立了一個 AP Leader group。
那因為大部分的科內配置，大多有科長與組長，通常當科長不在的時候會有組長作為代理，因此我們將科組長都列到這個群組成員中，像我這次的範例就是四名。
再來就是到Repositories-> repo name-> branch-> policies-> Automatically included reviewers進行設定。
這次我們把AP Leader加進去，而且我們最少審核者需要兩名，這樣當我們發Pull Request 的時候，這個群組中至少需要兩名成員按下許可的按鈕。但如果今天是設定多個個人或是多個群組，那表示已個人或是群組為單位，每個人(及群組代表）都需要按下認可，那這個欄位就會被反灰回來。
另外，之前我們在上面的branch policies有把 Require a minimum number of reviwers給打開，而且設定兩名。筆者在實驗的時候發現，如果下面指定了一個group 要approval，那上面這邊如果也打開來，上面的數字會排除在group中的成員。例如山姆大叔是在AP Leader group 裡面，那我的投票僅會強制被算在這個group中，並不會被重複計算到上面的review中。在這前提之下，我就先把上面關閉了。
上面講完AP Leader 的審核，現在要說Operator的審核設計了。因為實際上在佈署這件事情是直接寫在pipeline，當在hosted pipeline上面編譯好後，就會一路奔向environment去進行佈署作業了。那在Environment那邊其實也有審核機制的，我們看一下操作圖：
在這裡我把AP Leader 以及OP都帶入了，而且下了一些註解。這個設定會在Pipeline 要使用到這個資源進行佈署的時候，就會發信呼叫審核者須進行審核的動作。
Release note 其實是內部提出來，專門要提供給審核者以及未來查核者確認，到底每次要上線到營運環境的版本是否正確、相關檢核資訊是否也完備，都整理出來好讓審核人員以查核人員可以確認資訊。
我們目前打算做在wiki上，格式大概如下：
我們會要求每一次進版到正式環境，都需要填寫這一份初稿，而且在Create Pull Request時，就會把這份Release note 的連結上。也會把Pull Request的Link 也回填到這份wiki上。這樣的好處是，這份Release note 會敘述接下來要進行佈署營運環境的一些敘述，所以可以方便審核的AP Leader可以點入觀看。同樣的在觀看Release note的審核人員，也可以依據需求直接就點到Pull Request去進行細節確認。
那這份Release note 應該要落下一些資訊，我們認為應該要有：
那當然，上面這份算是我們的初版Release note，未來是可能因為其他人意見而在進行調整。但整份Release note 就是為了正視版本發布至營運環境的說明，並通知相關人等預計型的時間。
再來，就是讓我們試跑一次看看了。
iThome鐵人賽
看影片追技術